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I. ZOG BACKGBOQND 



A. IMTRODOCTION 

Cne of the first things a prospective computer user 
learns is that interaction with a machine is required if the 
user expects to realize the potential power of the computer. 
This interaction takes place via a human-computer interface. 
Depending on the design of the interface, there are varying 
degrees of usefulness which the user can achieve. It is 
safe to say that the more familiar one is with the interface 
the more computer power one has available. Suppose that the 
knowledge required tc become familiar with the interface was 
embedded within the interface. If such an interface was 
also simply structured and responded rapidly to commands, it 
would allow the user to quickly understand the power of the 
computer. ZOG is such an interface. 

ZCG appears as a rapid-response, large- net work, menu- 
selection huma n- comp u ter interface. [Ref. 1 : P-1] The 

basic data structure is a frame, which contains textual 
information and selection information about the related 
items. Tens of thousands of related frames exist in hier- 
archical networks called ZOGNETS. Selections allow the 

rapid traversal of ZCGNETS, the editing of frames, or the 
execution of programs. 

B. HISTOEI OF THE ZCG PROJECT 

ZOG has its origin in 1972, when a group of cognitive 
psychologists gathered at Carnegie-Mellon University to 
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investigate computer program Simula tions. i In particular, 
this group was interested in devising a method of using 
large scale simulations without prior knowledge of the 
programs or of the operating systems on the computers which 
ran the simulations. Three individuals (A. Newell, G. 
Eobertson, and D.M. McCracken) developed a uniform interface 
for these programs, but the first ZOG was short lived 
because of the limitations in terminal technology; 300 baud 
hardcopy was hardly rapid response. 

In 1S75 Newell and Robertson served on a technical advi- 
sory committee for a system called PROMIS (Problem Oriented 
Medical Information System) implemented at the University of 
Vermont Medical School. PROMIS turned out to be remarkably 
similar to ZOG and it utilized terminal technology which 
provided a response cn the order of . 5 seconds. 

This experience rekindled interest in ZOG, and in 1975 
the Office of Naval Research (ONR) began support of a small 
effort to further develop ZOG into an interesting interface. 
Several versions of ZOG exist on machines like the PDP10, 
VAX/11-780, and on the PERQ microcomputer. While developing 
ZOG on the minis, possible alternate implementations and 
difficulties regarding hardware and operating system 
constraints were explored. The desire to use the PERQ as 
the ultimate target machine was influenced by the parallel 
development of SPICE (scientific personal integrated 
computing environment) on the PERQ at Carnegie-Mellon. 
Planning included the use of some of the results of the 
SPICE research in the ZOG implementation. 



iThe hastorical information in this section is based on 
- R. M. Akscyn. D. L. McCracken. ^e ZOG Proj ect, Computer 
Science Department, Carnegie-Mellon University, 5 January 
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In 1980, Captain Eichard Martin, OSN, Commanding Officer 
for the commissioning crew of the USS CARL VINSON, visited 
the ZCG project. Ihe Captain had previously decided to 
incorporate computer science research to make CARL VINSON a 
test bed for leading scientific technologies in the fleet. 
After visiting many CNE research sites, he believed that ZOG 
would meet his goals for creating an onboard testbed for 
further research. Although the ZOG group had not envisioned 
the application of ZCG in such a real-time, large scale 
environment, the advantages of placing ONR sponsored 
research into the fleet were too great to pass up. 

The current ZOG-based management information system 
onboard CARL VINSON has a data base distributed over 28 PERQ 
computers. Applications cover four main areas: (1) an 

on-line Ship’s Organization and Regulations Manual (SOEM) ; 
(2) an interactive task management system which can use the 
SOEM to decide how tasks are to be performed; (3) a rule 
based expert system tc aid Air Operations in the launch and 
recovery of aircraft; (4) an on-line training manuals which 
interact with videodisk display units; and (5) an electronic 
mail system. 



Because this thesis is involved 
development environment for an expert 
focus will be on the third item. 



with enhancing the 
system in ZOG, the 



AIEPXAB: AH EXPEEI SYSTEM IN ZOG 



Ihe OSS CARL VINSON is an aircraft carrier and as such 
spends a substantial amount of time in the launch and 
recovery of aircraft. AIEPLAN is a rule-based expert system 
used as a decision tool for air operations officers in the 
launch and recovery evolution. The system is implemented in 
OPS7, a rule-based language, with ZOG used as the human- 
computer interface. 



From the beginnirg, the development of AIRPLAN has been 
incremental; a kernel of the expected system was put into 
the operational environment, and the environment has and 
continues to direct the direction of growth. In support of 
this incremental strategy, the system allows gueries about 
its data base and its behavior. "This ability to ask the 
system questions about its reasoning is useful for system 
developers trying to track down rugs, and for system users 
to both gain confidence in the abilities of the system and 
the correctness of its recommendations, and for eliciting 
additional or more detailed information on which to base 
decisions." [Bef. 2 : pp. 2-3] 
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II. I NTB ODDCTION 



A. A FBOGBAHflING E1VIBON9EMT 

What is a progra milling environment? To answer this ques- 
tion it is necessary to understand what is involved in the 
process of writing a computer program. Initially some 
problem specification must exist. With such a specifica- 
tion, an algorithm which appears to satisfy it is found. 
Given these two items, the algorithm must be translated into 
source code, executed and debugged. The cycle of code 

writing, execution and debugging continues until the human 
programmer is convinced to some predetermined degree that 
the program satisfies the problem specification. The task 
of managing all associated files and programs falls upon the 
programmer. 

Experience shows that this process is composed of many 
activities which are tedious, repetitive and detailed to the 
point where errors are commonplace. Examples of areas which 
create such problems include mastering a programming 

language syntax for creating and editing programs, and 
managing the compile/link/load process. It seems appro- 
priate that the computer should be counted on to perform 
these kinds of mechanical tasks, which it excels at, while 
the programmer concentrates on cognitive ones. To this end, 
the programmer should have sufficient tools available on the 
computer to automate these activities [Bef. 4 : pp. 4-5]. 

In such an environment, creating and maintaining programs 
can be the responsibility of a syntax-directed editor. The 
process of compile/link/load can be reserved for final 
production programs, since in the interactive environment an 
interpreter is better suited for program development. 
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The above is just an example of what an interactive 
programming environment can provide. For the purposes of 
further discussion, the following definition of an interac- 
tive programming environment will be adopted: 



First, within a unified framework, they provide a large 
set of tools- most of which are specific to a particular 
programming language. Second, they take advantage of 
the fact that programs have an underlying structure that 
is mere than a string of characters- using this struc- 
ture as an organizational tool. Third- they support 
incremental program development, in both the design and 
maintenance activities. Finally, they are highly inter- 
active in nature, promoting and exploiting a fairly high 
bandwidth of communication between the user ana the 
environment [Bef. 3]. 



B. TEE ZOG EN7IE0HHEMT 

The natural question which follows is, how does ZOG 
measure up to this mere formal definition of an interactive 
programming environment? The notion of a frame in a tree 
structure satisfies the requirement of a unified framework. 
In ZCG, the frame is used as a visual representation ef the 
data base for the user to see and manipulate; at the same 
time the frame is the structure used to store data in 
memory. These two separate ideas work this way. In memory, 
data is store in a complex PERQ PASCAL 2 record structure. 
For the user, the notion of a window frame exists. When the 
user requests to see data in memory, the data is unparsed 
into different fields of the window and presented on the 
screen. 



2pEEC PASCAL IS an extension of PASCAL which, among 
other features, supports high level string manipulation. 
The copyright of this extension is held by Three Rivers 
Computer Corporation, Pittsburgh, PA. 
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The second point cf using the underlying structure of a 
language as an organizational tool is present if one 
considers the language to be Pascal like. The inherent 
structure of Pascal encourages hierarchical stepwise devel- 
opment and modular design. ZOG develops its ZOGNETS is just 
this way. The frame at the top of a subnet contains its 
central theme. Options are created on this frame, and these 
options link to other frames which further explain the 
central theme. But this use of the underlying structure of 
Pascal seems to end here. There is little evidence to show 
that the developers of ZOG planned to support any particular 
programming language from within the environment. The lack 
cf any programming tods, such as interpreters, compilers, 
or syntax directed editors, makes this manifest. 

The ability to support incremental program development 
is one area where ZOG falls short. Currently it supports 
development of Pascal programs by writing the programs as 
text in frames and then running an agent ( a program 
executed from within ZOG which manipulates frames) which 
strips the text off the frames and creates a text file out 
in the machine* s operating system. What is needed is a 
method of executing parts of the program while still in the 
environment; this is the focus of this thesis. 

The bandwidth of communication which ZOG currently has 
is highly interactive and user friendly. Users find that 
movement around the subnets is intuitive and easily 
mastered. Straight-forward system utilities exist for the 
creation and modification of frames in the data base; time 
on the system rapidly makes the user comfortable with these 
utilities. 
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III. FRAME STRUCT ORE 



Thus far, ZOG has been viewed from a logical perspec- 
tive. This chapter will expound on this view and address 
the physical implementation of the ZOG frame in Perg Pascal. 
The intent is not to make the reader an expert in using ZOG, 
manipulating ZOG frames, or generating code in this version 
of Pascal. Rather it is hoped that the reader will gain a 
respect for the power and complexity of this environment. 

A. TEE LOGICAL VIEW 

The logical view has been defined as the user's window 
into ZOG. Understanding this view requires an understanding 
of the tasic parts of a ZOG frame and how they are put 
together. 

The hierarchical arrangement of frames in ZOG is in the 
form of a tree. This structure, called a net, has a root 
frame (called the top frame), and branches, or connecting 
frames. As implemented on the Perg Microcomputer, ZOG is 
one large net composed many subordinant nets, called 
subnets. Inherent to the net are different levels of infor- 
mation: the top frame of the net contains general informa- 

tion and points to frames with more specific information. 
This pattern continues until the most specific frames in 
the net, the leaves, are reached. Tne point is that every 
frame describing a particular aspect of the more general 
subject has a place in the hierarchy of the tree that is 
dictated by the logical structure of the subject matter 
[Ref. 5 : p.11 ]. 
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Every frame is divided into four component types called 
items; the frameid (frame identification), frame title, 
frame text, and selections (see figure 3.1). Selections, 
which represent choices of what to do next, are of three 
types: options, local pads, and global pads [fief. 5 : 

p.12]. 



THIS IS THE FRAME TITLE. IT GIVES FRAMEID 

A CONCEPTUAL NOTION OF THE FRAME’S 
CONTENTS. 

THIS IS THE FRAME TEXT AREA. THE TEXT PROVIDES THE 
CENTRAL IDEAS OF THE INFORMATION. 

THE FOLLOWING OPTIONS LEAD TO ELABORATIONS 
OH THE TEXT OF THIS FRAME. 



1. THIS IS THE FIRST OPTION 

2. THIS IS THE SECOND OPTION 



L. THIS IS A LOCAL PAD. IT IS A CROSS REFERENCE 
TO OTHER FRAMES. 

X. ACTIONS (AGENTS) CAN BE EXECUTED HERB. 



HERE ARE GLOBAL PADS. THEY ARE ENVIRONMENTAL TOOLS. 



Figure 3.1 Frame Layout. 

The frameid is the unique system label for every frame 
in the ZOG net. It contains the subnet name and frame 

number of that subnet. Frames in the same subnet have the 
same frameid name. 

The frame title is usually the text of the option which 
points to it. It can be considered the conceptual link 
between a frame and its parent. The text of the frame can 
be anything the user wants. 
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Selections are used to point to other branches in a net. 
The first type of selection is an option. It consists of a 
selection character and text. Options are used to point to 
frames that are logically more specific than the frame 
containing the option. 

The second type# the local pad# also consist of a selec- 
tion character and text. While the difference between local 
pads and options are negligible# local pads usually cross- 
reference other frames rather than following a strictly 
logical path. 

The final type of selection is the global pad. These 
are fcund across the bottom line of the frame and can be 
utilized by typing the first letter (always lowercase) of 
the desired pad. Global pads provide more choices for the 
user: more ways to move around nets# information about the 
frame’s history, and utilities for tasks such as creating or 
deleting frames. 

One other part of a frame is the user display. Zog 
communicates with the user on the last line of the frame# 
directly above the global pads. The display helps the user 
by suggesting what to do next# why a command from the user 
was net accepted# or where or not the editor is currently 
envoked [Bef. 5]. 

When frames in ZOG are created# they must originate from 
some frame schema. A schema is the generic frame for a 
subnet# and is created when a user elects to create a new 
subnet. The user designs the frame with anything on it# 
from options or text# to any number of local or global pads. 
This frame will now exist in ZOG as the zero frame in the 
subnet specified by the user. Subsequently# whenever 
another frame is created in this subnet# the default frame 
schema to be created will be the zero frame for the subnet. 
The option exists to use another frame schema# if desired. 
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B. TEE PHYSICAL VIEW 



In reality ZOG is simply a very large computer program 
(over 70,000 lines of source code). The ZOG system is based 
on the record structures provided by Pascal. A frame is a 
record containing as many fields as there are parts to the 
logical frame. Some of the parts are easily recognized, 
such as the frame title, the text, and the options. Others 
are less obvious, such as the frame owner (s), the frame 
protection, and the action hidden behind global pads. 

The field type declarations vary, depending of the 
nature and quantity of information that the field hclds. 
For example, the frame ID field is simply a string of no 
more than 15 characters. The text field is more complex 
because its data may be up to 21 lines of information 
(double sized frames exists, and these could hold more 
text) . To handle this, its field in the frame record points 
to another record, which points to a linear, doubly linked 
list; each element of the list contains a line of text. The 
source code for the frame structure can be found in appendix 
A. 

Just how is data stored into the ZOG database? By using 
the utilities provided by the system, the user can create a 
blank frame or a new subnet of frames into which data can be 
stored. The ZOG editor (ZED) is used to insert information 

into the various fields in the frame. Once the frame is 

saved, ZOG parses the different fields of the display frame 
(called the window frame) and stores the data into the phys- 
ical record frame. The retrieval of data follows the 
reverse path. After telling ZOG which frame you wish to 
see, it finds the physical record and unparses its fields 
into the window frame. It is interesting to note that the 
retrieval of a specific frame over the Ethernet takes under 
1.2 seconds. If the frame is located on the same machine as 
the user, retrieval takes .5 seconds! 
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C. SDHHABY 

From the perspective of an interactive programming envi- 
ronment both the logical and physical views are important. 
The logical view of the frame provides an intuitive under- 
standing of stored data as well as a mechanism for input and 
output for programs. The physical view provides the knowl- 
edge base required to design a tool in the environment. 



20 



IV. M EXPERT SI^EM X ANG OAGB: O PS7 



Because OPS7 is the expert system currently used by ZOG, 
a discussion of the language is appropriate. OPS7 is a 
member of the OPS family of production system languages 
designed by Charles 1. Forgy. Production systems represent 
a model of computation egual in power to, but very different 
in style from, procedural languages like Pascal, operator- 
oriented languages like APL , and applicative languages such 
as Lisp. This discussion will highlight the language's data 
structure, basic control structure, and conflict resolution 
scheme. Having this understanding will reveal the character- 
istics which lend OPS7 to integration within ZOG. The BNF 
(Backus-Naur Form) syntax for the language can be found in 
appendix B. ^ 



A. iOEKING MEMORY EIEHEHTS 

The only data structure used in 0PS7 is the working 
memory element. It is similar in form and function to 
Pascal's record structure. Fields in a working memory 

element can hold scalar values, vectors, or sets. The 
following is an example of a type declaration, a function 
call 'MAKE,* used to create an instance of the type in 
working memory, and a call to display a working memory 
element. Comments in 0PS7 start with a semi-colon and 
terminate at the end of the line. 



(type task 
Kind = scalar 

) 



status = set: 1 



values = vector: 3 



3The bulk of the information is this chapter comes from 
references 5 and 6. 
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; This fuDction creates an instance of 
; type task in working memory. 

(make task 

kind = sort status = ( on } values 

) 



12 3 ] 



(wme 1) 



task 

♦id* = 1 
kind = sort 
status = f on } 
values = f 1 2 3 



Call to display Working Memory Element 1 
What follows is the output. 

(Assumes this instance of TASK is 
working memory element 1.) 
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Scalar types can be either integers or symbolic atoms. 
Symbolic atoms may be any string of characters other than 
integers or anything enclosed by double quotes. Floating 

point operations are not implemented in 0PS7. Sets are 

defined as unordered collections of non-repeating scalar 
values. Curly braces delineate sets. Vectors are ordered 
collections of scalar values which may repeat. 

Cne must think of the working memory of an 0PS7 program 
as the knowledge base about the state of a problem. It 
contains instances of the declared types, which are created 
by the MAKE function, altered by the MODIFY function, and 
deleted by the REMOVE function. Working memory is 
constantly changing. It is this change which causes the 
expert system to transition from one state to another. 



B. EICOGMIZE AHD ACT CYCLE 

The basic control structure of any production system is 
the recognize and act cycle. On every cycle ox the 0PS7 
interpreter, an attempt is made to satisfy at least one left 
hand side of a production rule with elements from the 
working memory. This process defines a set of unique 
insta nc es in which left hand sides of productions may be 
satisfied on each cycle. From here the conflict resolution 
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scheme must determine which instance from this conflict set 
is suitable for firing. The following pseudo code for this 
cycle is found in reference 5: 

loop 

RECOGNIZE: 

determine the current set of instantiations; 
if the set of instantiations is empty, then halt; 

ACT; 

select 1 instantiation and execute its right hand side 
actions 

repeat 



C. CCHFIICT RESOLOTICH 

The purpose of the conflict resolution strategy is to 
select the next rule to fire. Ideally the execution of 
rules would be order independent so that such a strategy 
would not be required. But in reality such a set of rules 
rarely exists. Due to the nature of expert systems, the 
conditions for different rules will be similar. And as the 
working memory elements are created, modified, and deleted 
rules have a tendency to fire sequentially although that may 
not have been the original plan. 

Seme strategy must exist to determine which instantia- 
tion is to be selected from the conflict set if the set 
contains more than one element. In 0PS7, conflict resolu- 
tion is either specif cas e ^rst or mos t recent fi rst . If 
the set of conditions for a production rule P is a proper 
subset of the conditions for production rule Q, then rule Q 
will fire first. Rule Q is more specific than P because of 
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its additional conditions, hence the interpreter should 
address the more detailed prior to the more general case. 

If the working memory elements which satisfy the condi- 
tions for production rules P and Q differ only in that the 
elements for P were created or modified more recently than 
those for Q, then rule P will fire. Thus, expansion is 
depth first in that once a path is followed, it will be 
continued as far as it can go before branching out. 

This strategy introduces order into a potentially 
chaotic situation. Obviously, it is necessary if the 
’expert' is to have any control over the system. Knowledge 
of the mechanism at work allows programming of specific 
tasks though the control flow may be subtle or possibly 
convoluted. 

D. k SAHPLE PBOGBAH 

As with any language, learning its primitives and syntax 
is the major hurdle to successful programming. But our 
purpose is to determine the suitability of 0PS7 for integra- 
tion into ZOG. To this end, a small sample program will be 
reviewed. The particulars regarding items such as input and 
output syntax are not important to this example. If the 
reader has further interest in such matters, see [Ref. 7]. 
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This program asks the user to input numbers and, when 
told to sort, will print out the numbers in ascending order. 
To preserve simplicity no error checking is performed. 

TYPE DECIARATIONS 



(type number 

value = scalar ) 

(type task 

type = scalar ) 

PRODOCTICN HOLES 

(p readin 

i (task type -•= sort 



— > 

(write "Input an Integer — 

LA/*/: 



number schema 



task schema 



; A rule called READIN 

; Read as long as the input 
; is anything but the word 
; ’sort’. NO ERROR CHECKING 
; ’i’ is a label. 



II 

Input message 



(modify i type = 

(index (accept) 1) 

(make number value = 
i;type ) 

(p sort 

(task type = sort) 
j (number value -•= sort) 

- (number value -•= sort 

value < icvalue 

) — > 

(write 

) 

(remove j) 

INPOT DATA 
(make task) 



; Read value into task type 



Make another INSTANCE of 
number using the same value ) 



; A rule called SORT 

; Task is now sort 
; (as entered by user) 

; Find a number j which 
; is not = sort, 

; (’j’ is a label) 

; and there is NO value 
; (including ’sort’) 

; which is smaller than j 



out the smallest value 



working memory ) 



1: va lue 

[/ * 2 ; Print 



Remove this value from 



Create an instance of task 
to start the system 
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The order of entry is important in 0PS7; type declara- 
tions, rules, and then input data. Generally, the instances 
created by the input data establish the working memory 
elements required to start the system. The type declara- 
tions are easy enough to understand. Two types are 

declared, both of which hold scalar values. The INPUT DATA 
makes an instance of type task and assigns its field type 
the default scalar value of ’?’. Placing this in working 
memory causes the first p rule, READIN, to fire. READIN 
assigns the input value to both number value and task type. 
This rule will continue to fire until the work *sort' is 
typed and entered. Once this happens, p rule SORT will fire 
because the task type = sort and there exists (at least one) 
number value NOT equal to sort. The beauty of 0PS7 is seen 
in this simple production: the interpreter has been 

instructed to search working memory until it find a value 
'j* which is smaller than any other value (not equal to 
*sort’). This smallest value is printed to the console and 
removed from working memory. SORT continues to fire until 
all number value instances, except value = sort, are removed 
from working memory. At this point there are no working 
memory elements which can satisfy the right hand sides of 
any p rules, so the system halts. Essentially, this is a 
program which will sort from one to many numbers (restricted 
by memory size) using only one rule! 

£. SDHHARY 

This review shows that there is a structure in the 
creation of an 0PS7 system which can be supported by a hier- 
archical environment such as ZOG. Specifically, subnets in 
ZOG can be the structures for storing type declarations, 
working memory (each frame containing a single working 
memory element), production rules, and the conflict set. 
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The job of the interpreter will be to know the location of 
these subnets and what to do with specific types of frames. 
The next chapter will discuss the design of the frames for 
each such subnet. 
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?. FBAME SCHEMA DESIGN S 



A. INTBCDOCTIOH 

New that there is an understanding of the frame struc- 
ture in ZOG and the format of 0PS7, the next step is to 
develop subnets which the new interactive interpreter will 
use, and to detail the basic design of the generic frame, or 
schema frame, for each subnet. A subnet is required for: 1) 
each system subnet used and maintained by the interpreter, 
and 2) each user subnet upon which the user can develop his 
programs. It follows that each subnet should have a unique 
frame schema so that the interpreter knows what tc expect 
each time it refers tc it. The unique schemas take advan- 
tage of the structure and syntax of 0PS7 for writing 
programs and organizing subnets. 

The first consideration for schema design is whether the 
information written on the frames should be frame text or 
frame options. Because each of these parts of a frame are 
implemented as selection pointers, it makes little differ- 
ence to the system which one is used when trying to find 
information on the frame. If the frame item is to point to 
another frame, options are required. It is also preferable 
to have frames which contain only text, without selecting 
other frames. For these reasons both text and options are 
used . 

The use of the frame determines which global pads are 
displayed. Those frames which are created by the user will 
have a standard set of global pads (table I) . Those frames 
created, modified, and removed by the interpreter will 
contain a similar set except 'edit* will not be available. 
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TIBLE I 

STAHDAED GLOBAL PAD SET 



EDIT 

HELP 

BACK 

NEXT 

PREV 

TOP 

GOTO 

OTIL 

DISP 

INFO 

BIN 

joap 



RON 'edit*, THE ZOG EDITOR. 

DISPLAY THE TOP FRAME OF ZOG USER'S GUIDE 
IN THE OTHER WINDOW. 

BACK UP ONE FRAME IN THE BACK-UP STACK. 

DISPLAY THE NEXT OPTION FROM THE SELECTION FRAME. 
DISPLAY THE PREVIOUS OPTION FROM 
THE SELECTION FRAME. 

DISPLAY THE TOP OF THE NET (FOR THE 
PARTICULAR MACHINE) . 

GO TO SPECIFIED FEAMEID. SYSTEM WILL PROMPT. 
DISPLAY THE TOP FRAME OF SUBNET ZOG. SHOWS 
AVAILABLE AGENTS AND ACTIONS. 

REDISPLAY THE CURRENT FRAME. 

DISPLAY FRAME MAINTENANCE INFORMATION 
MAKE THE OTHER WINDOW THE CURRENT WINDOW. 

PUT THE CURRENT WINDOW FRAME IN THE OTHER WINDOW 
AND CHANGE WINDOWS. 



The subnets for this proposed OPS7 system contain all 
the information that the interpreter requires for proper 
execution. Each have unique characteristics causing the 
appropriate results when it interacts with the interpreter. 
The requirement for subnets can be divided into two types; 
those created by the user and those created by the inter- 
preter. The user subnets are the working areas in which 
declarations, rules, and actions are written by the 
programmer. Characteristic of these subnets are frames 
which allow editing for the purposes of writing OPS7 
programs. The interpreter, or system, nets are similar in 
form to the user nets, except editing of the frames is 
denied. This is accomplished by write protecting the frames 
and by removing the 'edit' global pad from the frames. This 
prevents the user from circumventing consistency checks done 
by the system. System subnets are required for type decla- 
rations, production rules, working memory, and the conflict 
set. What follows are specific designs for the schema 
frames for each subnet. 



29 



B. IBE OSEB SOBHETS 



When the user elects to write OPS7 programs in ZOG, the 
first frame presented to him is the environment frame for 
the agent. Agents topically reguire one or more user- 
specified parameters, such as subnet name, or output file 
name, in order to run. Environment frames were created to 
provide a means of passing this information to the agent. 
These frames use their options as 'slots’ that hold this 
input data. The slot editor is used in conjunction with 
these frames to provide the user a simple method of 
inserting the desired information. 



ENVIECNMENT FEAME OPSO 

1. SAME OF THE PEOGEAM SUBNET; 



X. EXECUTE 

GLOBAL PADS (To include the slot editor 'SLED') 



Figure 5.1 OPS7 Environment Frame. 

[Ref. 8]. In this instance, the user selects the slot 
editor and, following a prompt for the subnet name, fills in 
the name of the subnet he wishes to use. Error checking 
done by the slot editor prevents entering an invalid subnet 
name. The exection local pad on the environment frame 
causes the agent to begin execution on the given subnet. 
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If the subnet already exists, the agent presents the top 
frame in the subnet in the current window and the user 
proceeds as desired. If it is not present, the agent 
creates a new subnet using the name from the input slot and 
copying the PROGRAMO frame as a schema (see figure 5.2). 
Ihe system then creates the subnets for types, rules, and 
actions under the respective options, using the following 
naming convention. The subnet names include the subnet 
function (type, rule, or action) appended to the end of the 
subnet name from the input slot, not to exceed 12 charac- 
ters. lor example, for a program name of AIR, the subnets 
are called AIRTYPE, AIRROLE, and AIRACTION. If need be, 
letters are truncated from the input slot subnet name. The 
development of these subnets is discussed later. The 
PROGRAMO frame schema contains the standard set of global 
pads and a set of six local pads: Load, Run, Halt/Continue, 

Working Memory, Conflict Set, and Error Msgs. The Load pad 
is selected once the program has been entered. It tells the 
interpreter to evaluate the program statements for syntax 
and type errors. The Run pad explicitly tells the system to 
commence evaluation and execution of the PROGRAM frame. The 
Halt/Continue pad allows the user to arbitrarily stop a 
running 0PS7 program in order to go to other frames and 
analyze program actions. The Working Memory pad is a link 
to the existing working memory subnet. The Conflict Set pad 
links this frame to the conflict set subnet. The Error Msgs 
pad is the link to a frame which contains the text of the 
system error messages. Having these local pads makes the 
0PS7 actions, (wm) and (cs) , obsolete as debugging commands. 
The top frame organizes the program into these specific 
subnets to make program creation and debugging easier for 
the programmer. Note that all schema figures may also 
include the syntax for possibl e entries into the frame. 
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Cn the top frames of each of the three subordinate 
subnets is where the programmer writes type declarations, 
production rules, and actions. Each entry is a single 
option on the frame. In the case of type declarations and p 
rules, only the first line of the declaration appears on the 
appropriate frame. For single actions not appearing as p 
rule right-hand-sides, the entire action statement is 
entered. For types and p rules, additional frames must be 
created to contain the body of these parts of the program. 



Program 


PROGEAMO 


1. TYPES 






2. ROLES 






3. ACTIONS 


L. 


LOAD 




R. 


RON 




H. 


HALT/CONTINUE 




W. 


WORKING MEMORY 




C. 


CONFLICT SET 




E. 


ERROR MSGS 


GLCBAI PADS 







Figure 5.2 Program Schema Frame. 



1 D eclarations 

Ihe schema for the type subnet is a frame with the 
standard global pads and two local pads (Figure 5.3). 

This top frame is created by the agent and is linked to the 
top frame in the user subnet. The subnet name for this 
subnet comes from appending the word 'types' on to the first 
seven letters of the user program name. The local pad. 
More, directs the user and the interpreter to additional 
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“I 



<SYHBOL> TYPEO 

1. <SYMBOL> 

2. <SYMBOL> 

3. <SYMBOL> 

4. <SYMBOL> 



M. More types 
P. Parent rrame 



GICBAL PADS 



Figure 5.3 Type Schema Frame. 

type declarations should more than nine be needed ( there 
are a iraximum of nine options per normal frame). While the 
More pad is not the most efficient way to traverse a list of 
itemS/ this system should not have to support a program with 
more than two frames worth of types. The issue of program 
size is addressed later. The parent pad directs the user to 
the current frame's parent. 

To create type declarations the user selects the 
TYPES options on the top PEOGRAM frame. This selection 
leads to the top of the type subnet. The programmer then 
selects edit and enter the first type as an option. Once 
out of the editor, the desired type is selected and the 
ELEMENIO schema is explicitly reguested. This frame is 
created and the editor is automatically entered (see figure 
5.4). The body of the type declaration is entered as text, 
in accordance with the 0PS7 syntax, and saved. When the 
interpreter encounters the TYPE option on the top PROGRAM 
frame, as it process the frames beneth it, it enters the 
types found in a subnet called GlobalNet; This process is 
explained in section C. 1. 
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<SYMBOL> ELEMENTO 

<TYPE-FIELD> 

<TYPE-FIELD> 



<TYPE-FIELD> 

<TYPE-FIELD> 

. M. More elenents 

. P. Parent frame 

GlCBAl PADS 



Figure 5.4 Type Element Schema Frame. 

2 . P R ule s 

The body of p rules are entered like types using a 
schema similar to TYPED, except the More pad leads to ’More 
rules.’ This schema is called RULED. The tree below this 
frame differs from the types tree because at least two 
frames are needed to contain a single p rule: one for condi- 
tions and one for actions. The schema frame for conditions 
contains the standard global pads and the same local pads as 
TYPED. The use of a More pad is considered sufficient here 
because in most cases rules can be expected to have fewer 
than twenty-one conditions (there area maximum of twenty-one 
line of text per normal frame) . The conditions are entered 
as text on these frames. The bottom of the condition frame 
contains an option ’ — >’, which points to the actions for 
the given p rule. This option does not appear if there are 
more conditions on another frame. Figures 5.5 and 5.6 
illustrate these schema frames. 
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The action schema frame is a frame like ELEMENTO, 
with the standard set of glohal pads and the local pads. 
More and Parent. Actions which appear on the right-hand- 
side of production rules may also stand alone as commands in 
0PS7. The standard use for these kinds of actions is to 
create some initial state in working memory so the program 
starts when run is selected. This subnet is modified by 
selecting the ACTION option at the top of the user subnet, 
selecting 'edit' on the frame, and entering the action as 
text. 



( P <SYMBOL> 


CONDO 


<CCNDITION> 




<CCNDITION> 




<CCNDITION> 




<CCNDITION> 




• 


M. More conditions 


• 


P. Parent frame 


• 

— > 




GlCBAl PADS 





Figure 5.5 P Buie Condition Schema Frame. 



C. SISTEH SOBNETS 

The system subnets are those created and maintained by 
the interpreter. The subnets reguired by the interpreter 
are for global variables, working memory elements, and the 
conflict set. They are called GlobalNet, WM, and CS, 
respectively. These subnets are created the first time the 
interpreter is called to load a program. Subsequently, any 
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1 



— > ACTICNO 

<ACTION> 

<ACTICN> 

<ACTICN> 

<ACTICN> 

. M. More actions 

. P. Parent frame 

GICBAl PADS 



Figure 5.6 P Rule Action Schema Frame. 

time another program is loaded, they are cleared out so the 
system can start from scratch. The subnet names for these 
nets are not concatenated with the name of the user program 
subnet because they are independent of any particular 
program. As previously mentioned, security is maintained in 
these subnets by DENYING the user the ability to edit system 
subnet frames. 

1 . G lobal Subn e t 

As the interpreter is processing, each time a type 
declaration is round it is inserted into the GlcbalNet. 
This is the system’s reference mechanism whenever it is 
creating an instance of a declared type for working memory. 
This came comes from the fact that all variables is 0PS7 are 
global [Bef. 6]. 

Adding an entry into this subnet is a two step 
process. First, the type name (0PS7 syntax for this is 

<SYMBCL>) must be written as an option in the top frame of 
the subnet. Figure 5.7 shows the top frame in the GlobalNet 
subnet. 
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GLOBALNETO 



GLOBAL VARIABLES 

1. <SYMBOL> 

2. <SYMBOL> 

3. <SYMBOL> 

4. <SYMBOL> 

. M. More variables 

. P. Parent frame 



GLOBAL PADS (EXCLUDING 'edit'). 



Figare 5.7 GlobalNet Schema Frame. 

The sscond step is the creation of the frame which 
has the actual declaration. This frame contains information 
as text. To insure security of system nets, a copy of the 
type elements frame from the user subnet, TYPES, must be 
copied into this frame. Simply establishing a link between 
the GlobalNet and the TYPES subnet would allow the user to 
edit frames used by the system. The system does not create 
these frames until they have been found syntactically 
correct by the interpreter. 

2. forking, Memo ry 

The working memory subnet is used by the system to 
hold working memory elements, which are specific instances 
of the previously declared types. The top frame in this 
subnet is similar to that of the GlobalNet except its subnet 
name is NM (refer to figure 5.7). The subordinate frames in 
this subnet use ELEMENTO frames as the schema. When the 
interpreter encounters the function MAKE (implicitly or 
explicitly), it creates an option on the top WM frame and an 
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instance of that tjpe from GlobalNet is copied into the 
Working Memory subnet. 

This subnet's element frame differsfrom the 
GlobalNet's type schema in tbat the values assigned to the 
various fields of the element are included in the text. 
Each value is appended to the end of the text containing the 
type^ field. As seen in figure 5.8, the character 



<SYMB01> 

<TYPE-FIELD> ==> <ANY-VA10E> 
<TYPE-FIELD>==> <ANY-VALUE> 
<TYPE-FIELD>==> <ANY-VA1UE> 
<TYPE-FIELD>==> <ANY-VAL0E> 



ELEMENTO 



M. More elements 
P. Parent frame 



GLOBAL PADS (EXCLODING 'edit'). 



Figure 5.8 Working Memory Element Schema Frame. 

string '==>* separates the declaration from the value. The 
creation of the working memory element requires writing the 
element name ( <symbcl> ) on the top frame in the WH subnet, 
copying the type information frame from the GlobalNet into 
its element frame, and writing the explicit values (or the 
defaults) assigned by Make. 

A potential problem arises when one considers how 
many working memory elements might be created during a 

program run. It is difficult to estimate this because it 

depends not only on the nature of the program, but also on 

the different ways a program can be executed. What is 

known, is that the conflict set must have a unique way of 
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identifying each element in working memory. Ihe solution to 
this is to use the selection number of the working memory 
element option appended to the number part of the frameid to 
create a unique identification number. When a working 
memory element satisfies a p rule condition, the above 
number is passed to the conflict set subnet. 

3 • Confli ct Set 

The OPS7 conflict set contains the p rule name(s) 
and the ID numbers cf the working memory element (s) which 
satisfy conditions of the particular rules. Using the 
example frcm the previous chapter, if the p rule SORT had 
its two conditions satisfied by elements 1 and 9 from the 
working memory, then the response to the 0PS7 action (cs) 
would be to display the conflict set 'SORT [1 9].* The 
conflict set may contain zero, or more elements. 



CONFLICT SET 

<SYMEC1> [ELEMENT ID NUMBERS] 
<SYMEC1> [ELEMENT ID NUMBERS] 
<SYMEOI> [ELEMENT ID NUMBERS] 
<SYMEC1> [ELEMENT ID NUMBERS] 



CSO 



GICBAI PADS (EXCLUDING 'edit'). 



M. More 

P. Parent frame 



Figure 5.9 Conflict Set Schema Frame. 
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In the ZOG implementation of OPS7 the conflict set 
is kept on frames in a specificly created subnet. The 
schema frame for this subnet is a frame with the standard 
global pads without ‘edit * , and local pads for Parent and 
More. Ihe conflict set information is written as text. 
Figure 5.9 illustrates this schema. This subnet is used 
cnce the run command is executed at the top of the user 
subnet. Every time the recognize and act cycle completes, 
the information on this frame is updated because the p rule 
which just fired must be removed. Remaining unfired rules 
are also deleted if the change in Working Memory caused by 
the firing of the previous rule invalidated a rule in the 
conflict set. 

D. SOHHABI 

The subnets defined here are the mechanisms through 
which a user can use 0PS7 in the interactive ZOG environ- 
ment. Being able tc do this on ZOG frames takes advantage 
of ZCG’s hierarchical organization and fast retrieval of 
information. But there is still an important piece of the 
puzzle missing. The 0PS7 interpreter envisioned must be 
called from within ZCG to create, execute and most impor- 
tantly, debug programs. Hopefully, these subnets establish 
an intuitive framework within ZOG for the programmer and the 
interpreter. 
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the foundation laid by previous chapters, this 
outlines the characteristics of the interpreter to 
in this system. This is done by reviewing three 
1) the nature of the design for 0PS7, 2) what 

the interpreter will have, and 3) issues which will 
affect the practicality of the implementation. 



A. DESIGN NATURE 

In trying to decide just what the interpreter for this 
system should look like, two distinct choices were apparent. 
First, the system could be an interface between the existing 
ZOG system and the current 0PS7 interpreter. Essentially, 
this would mean creating a layer of software between ZOG and 
CPS7 for the purpose of formatting data into a useable form 
for each system. Although the appearance of 0PS7 in ZOG 
would be hierarchical and more interactive, it really would 
be the old interpreter in disguise. This approach sidesteps 
the entire issue of designing a new tool for the environ- 
ment. The second choice is to integrate the features of 
0PS7 into ZOG itself. To do this 0PS7 must be able to 
communicate to the user via ZOG mechanisms while continuing 
to evaluate and execute programs correctly. 

The decision of which option is preferable is based on a 
number of engineering issues such as the time constraints on 
the design project and the compatibility of the 0PS7 system 
with ZOG. The determination of which implementation 
approach is easier, is not trivial due to the complexity of 
ZOG and 0PS7. If the project were time sensitive, the 
method which would get a system up and running the fastest 
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is the obvious choice. Comparing this research with ether 
projects may provide some insight into this decision. 
Regarding compatibility# the two systems are currently 
written in the same programming language, and 0PS7 programs 
have an inherent hierarchical structure like the organiza- 
tion of data in ZOG. While the use of the same programming 
language does not imply compatibility, the similarity in 
organization of the two systems does. 

It is because of the desire to implement 0PS7 under 
Z03*s control and the compatibility of system organization 
that the latter direction is chosen. 

B. AGENT FEATURES 

The interpreter, which currently comprises 14 modules, 
will be integrated into ZOG as an agent. Agents are basi- 
cally processes within ZOG which know about ZOG structures. 
Typically agents operate on subnets of frames, or portions 
thereof £Hef. 8]. Their main purpose is to extend the func- 
tionality of ZOG. Agents differ from system utilities in 
that the latter are components of ZOG. The former are 
programs that are separate yet called from within ZOG 
[Ref. 5]. 

There are many features which will be a part of the 
design of this interpreter, and will perform implicit tasks, 
such as the creation of the Working Memory and Conflict Set 
subnets. The user will interact with the explicit features 
for the creation and debugging of programs. To illustrate 
how the agent will work, a sample programming session will 
be discussed. 

In ZOG, the programmer will select the 0PS7 interpreter 
by calling up the net utilities frame and choosing to run 
the CPS7 agent. If the subnet name given to the environment 
frame is not found, the agent will create a total of seven 
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subnets. For the user, the top PROGRAM frame with the three 
options is created. Each option points to the respective 
subnets for types, rules, and actions. When the system 
initialization is complete, the top frame in the user subnet 
will be in the current window. The programmer may now enter 
statements on the user frames by selecting the appropriate 
options. As described in chapter 5, only parts of the 
statements may appear on the top user frames for types and 
rules. The programmer may choose to first enter all the 
required syntax for these frames in a top-down fashion, or 
to enter the statements and its body (on a connecting frame) 
before proceeding tc the next option on the parent frame. 
The latter approach is called depth first. The top-down 
method is faster because the top frame in the subnet will 
only have to be opened and closed once. 

When the program has been entered the user must return 
to the top frame and select the Load local pad. This will 
cause the interpreter to traverse the program subnet 
performing type checking, creating the GiobalNet, WM, and CS 
subnets, and performing any actions present. At this time 
CPS7 will also put the production rules into what it calls 
production memory. Essentially, this is a translation of 
the language syntax into a more compact form for use by the 
production system part of the interpreter. Any errors 
detected during the load phase, will be announced to the 
user’s display on the current frame and written to an error 
message frame. This frame is found by returning to the top 
frame in the user subnet and selecting the local pad E. The 
errors will be options on the Error Hsgs frame; these 
options will be linked backed to the frame in the user 
subnet which contains the error. 

Suppose the program has been correctly entered and 
loaded. Now the Run local pad is selected. This action 
causes the recognize and act cycle to commence. 
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Communication with tte user is accomplished through the user 
display of the current window (which is at the top of the 
user subnet). Although the mechanics of this process are 
transparent to the user, the interpreter searches through 
working memory trying to find elements to match the left- 
hand-sides of production rules. 

As the production system is firing its rules, three main 
things are happening. First, the conflict set subnet is 
continually expanding and contracting as conditions are 
satisfied. Closely connected with this is the second 
activity, the creation, modification, and removal of items 
from the working memory subnet. Most important is the third 
activity: the system I/O with the user. This takes place 

in the user display, and allows a somewhat limited method of 
communication with the program. 

While the production system is running, it would be 
advantageous to allow the user to look at a system subnet, 
such as WM or CS, in order to follow what the pregram is 
doing to. A feature implemented specifically for AIRPLAN, 
called incremental display, would prove useful in imple- 
menting this capability. Incremental display has ZOG update 
the visual representation of a frame, which is displayed in 
one of the ZOG windows, whenever the physical information 
for that frame, in secondary storage, has changed. 
Implementing this while 0PS7 is running could prove to be 
impractical because a software level interrupt would be 
required to tell ZOG to update the displayed frame. 

In the event that the program has a semantic error which 
causes, for example, the program to terminate prematurely, 
the user may want to survey what the system was using for 
working memory or what was contained in its last conflict 
set. This is done by returning to the top of the program 
subnet (if not already there) and selecting the appropriate 
local pad. This feature has the potential to greatly 
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enhance the process of debugging, because while the program 
listing is in the bottom display window, the upper window 
can be used to traverse the desired subnet for debugging. 
Take the situation above. To find out why a program has 
halted ore may want to view the condition frame of a p rule 
while viewing the contents of particular working memory 
elements. The next and previous global pads can be 
extremely helpful in this situation by allowing the 
programmer to move from condition frame to condition frame 
of different p rules without returning to the parent frame 
holding the selections. Similarly, elements of working 
memory may be viewed. 

As previously mentioned, the programmer will be denied 
the ability to edit system subnets via global pads. But 
there does exist an alternate method of entering the editor 
on the current frame. If the user logged into ZCG is the 
frame owner, the editor may be selected by typing control-d, 
followed by e. One would only want to do this to manipulate 
memory elements that might be hindering a program’s devel- 
opment. The bug creating the specific problem could be 
overlooked in order to allow the program run to completion. 
The freedom to do this would be restricted by having the 
agent make a special owner assignment when creating the 
system subnets. The password to log in as this special user 
would be limited to the 0PS7 implementor (s) . It is their 
responsibility to realize the unpredictable results which 
may occur if illegal modifications are made to subnets main- 
tained by the system. 

C. IBPLEHEHTATION ISSOES 

Because the interpreter and the interactive environment 
are real world systems, it is appropriate to discuss some 
known issues which must eventually be dealt with if such a 
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project is to ever te implemented. While this section 
attempts to bring to light implementation guestions and 
suggest possible solutions, in no way is the domain of solu- 
tions limited to the author’s knowledge nor the limitations 
of the current systems. While some of the issues may seem 
prohibitive, the impact of future technological capabilities 
can not te dismissed. 

1 . Wri tin g to PCS file s 

An initial question is how an 0PS7 program in the 
ZOG system will be saved into a PSRQ Operating System (POS) 
file. The capability to write the information from frames 
into operating system files currently exists in ZOG. The 
agents designed to do this must be modified to read the 
program from the subnet in the proper sequence. The ability 
to do this is necessary because programs may be smaller 
components of larger 0PS7 programs too big for use in ZCG. 
This integration of modules is currently envisioned to be 
done outside the developement environment. 

2 . Pro gra m Siz e 

Program size is an issue which impacts the design of 
every subnet in the proposed 0PS7 implementation. When 
considering size, cne should look at an existing expert 
system. AIBPLAN is the only one currently implemented in 
0PS7. In its present form, it uses about 200 p rules. The 
goal cf this research was to create a development environ- 
ment for small programs or parts of larger programs. Hence 
a program of AIRPLAN’s size and complexity was not planned 
to run in this environment. This decision may seem arbi- 
trary, tut the author felt that if this system could be 
implemented with this limit, expanding it to support full 
OPS7 programs could be dealt with later. Specif ically, the 
author envisioned the ability to support programs about 
one-fourth the size cf AIRPLAN. 
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- • S. sr^ar € Limi t aticn s 

Another issue is the implementation of ZOG and 0PS7 
together on the PERQ. The PERQ can support 32,000 16-bit 
words of global data (in Pascal, under the PERQ Operating 
System). The current version of ZOG uses about 24,000 

global words. 0PS7 requires 23,000 global words. One can 
reduce this number by converting large structures (frames on 
down to individual strings) from static variables (currently 
managed by ZOG) to dynamically allocated structures using 
the Pascal NEW call. This still requires the use of a 

32-bit pointer to the structures in the global word area of 
memory, and the pointer will have to be dereferenced every 
time the structure is referenced. The dereferencing will 
add seme extra time overhead. It is possible to combine ZOG 
and CPS7 on the PERQ using this method. 

A more pressing problem is the amount of primary 
memory available. When ZOG was first put on the PERQ, the 
implementors tried to include a Pascal Compiler. This 
resulted in the system swapping so much that it was func- 
tionally brought to a standstill. The simple solution is to 
hope for the availability of a larger memory board for the 
PERQ. Currently, an upgrade from 1 Megabyte to 2 Megabyte 
memory boards is being investigated onboard the Carl Vinson. 
Without such a change, the only option available would be to 
include in ZOG a subset of OPS7. The majority of the 
globals for 0PS7 are concentrated in two modules. This 
implies that some sort of reduction of the standard CPS7 may 
be possible £Bef. 9]. 

4. Benefits of CPS7 in ZOG 

Cne might ask what is the benefit of having 0PS7 in 
ZOG in terms of the time required to simply type in the 
subject program. In other words, will the programmer spend 
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more time trying to enter a program in ZOG than he otherwise 
would typing it into a text file. Based on experience with 
AIRPLAN, the following can be said. Unquestionably, for an 
inexperienced user, the use of a text editor is definitely 
preferred over ZOG. This is because the user wculd be 
spending mcst of the time trying to understand how ZOG 
works, rather than concentrating on program creation. Once 
the user becomes more familiar with ZOG, the time required 
to create an 0PS7 program should decrease dramatically. 

ZOG is designed to be an intuitive, easiy tc learn, 
human-computer interface, but in reality, it takes hours of 
use before the user can adroitly construct trees and edit 
frames. In this implementation, the ZOG environment would 
be used to add organization to 0PS7 but not make it easier 
to type in programs. Hopefully, the benefits of having 0PS7 
in ZCG will more than compensate for the increased overhead 
required to use ZOG frames. 

5. System Execution Time 

The time required to run this system is interesting 
to analyze. Fairly good numbers exist for determining the 
time it takes to read a frame from disk memory into the ZOG 
Pascal record structure. For a local frame it takes 0.5 
seconds to read a small frame; 1.2 seconds are required for 
a remote frame. The time to modify a frame (an Open 
followed by a Close) is approximately double the read time 
[Eef. 9]. The time required to locally create a small frame 
is estimated to be approximately 2 seconds. The following 
is an estimation of the time required to load and run the 
number sort program in Chapter IV. 

This program has two type declarations. The inter- 
preter will open the type frame to find the first type name 
and the location of the element declaration frame. It will 
then open the GlobalNet and write in the type name as the 
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first option, followed by copying the declaration frame into 
a newly created frame pointed to by the GiobaiNet option. 
This process requires the opening and closing of a minimum 
of three frames and the creation of another. This must be 
done for every type declaration. Therefore, about 5 seconds 
will be required to lead each type, or a total of 10 seconds 
for the program. 

Beading the p rules into the system production 
memory requires reading the rules frame for the individual 
rules, and reading both the condition and action frames. 
For each rule, a minimum of three frames must be opened and 
closed; this will take about six seconds. Allowing time for 
the reading of the rule into memory means each p rule will 
required about seven seconds. The two p rules in the 
example will require 14 seconds to load. 

The single action in this program is read from its 
frame and the 'make* directs the interpreter to create a 
working memory element. This process requires the opening 
and closing of two frames, the reading of another, and the 
creation and modification of a third. It is estimated that 
this will require 4.5 seconds (3.5 of which is required to 
create a working memory element). The total time required 
to load this program is about 28.5 seconds. 

frogram run time is determined by following the 
action of the program. When run is selected, the system 
will attempt to find matches for the p rule conditions in 
working memory. This process requires the system to read 
every working memory element for each p rule. To do this 
the top frame in the WM subnet is read for the element IDs 
and the pointer to the element values. In other words, on 
every recognize and act cycle at least two frames must be 
read per working memcry element. Then, each time a match is 
found for the left-hand-side of a p rule, the CS subnet must 
be opened so the new member of the conflict set may be 
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entered. It will take 3 seconds to fire the first rule. As 
working memory increases the time required to read working 
memory will increase linearly. The time to create the CS 
subnet will depend on the nature of working memory. 

The readin rule will continue to fire until the word 
•sort* is entered by the user. The time between user inputs 
is devoted to making a new memory element, modifying 
another, and determining the conflict set for the next 
recognize and act cycle. This will take about 1 second more 
for every new number added. Entering five numbers to be 
sorted, plus the word sort will take at least 40 seconds. 
The processes to perform the sort will take about the same 
length of time. 

All told, the loading and running of this small 
program, assuming the subnets are local, will take at least 
110 seconds. This is due mainly to the time required to 
create, open, and close so many frames. The same load and 

run process on the existing OPS7 system takes only about 10 

seconds! This is a tenfold decrease in performance. 
Extrapolating these performance figures to a program 
containing 25 rules may make the new system intolerably 
slow. 

A method to increase performance is not clear 
because the bottleneck lies in the overhead for reading 
frames from disk storage. Like the previous issue of main 

memory size, the only solution to increased speed may be 

found in improved CPD technology. In any case, the benefit 
of having 0PS7 in ZCG will have to be weighed against this 
degredation in execution performance. 
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0. S0HH2B7 



The issues 
be considered, 
erations that 
this research 
this research 
if it to have 



addressed here are by no means all that need 
but they do represent the real world ccnsid- 
must be faced for projects in general, and 
in particular. Should the schemas proposed by 
be implemented, these issues must be resolved 
any impact on interactive programming. 
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VII. CONCIDSIOHS AND RECO MMENDATIONS 



A. CCNCIOSIONS 

Ihis research was an investigation into the design of 
an interactive programming environment. The reguirements 
for such an environment were initially studied. This 
research showed that the environment should (1) provide 
tools specific to the supported language, (2) use the under- 
lying structure of the language in designing the environ- 
ment, (3) support incremental program development, and (4) 
support a high bandwidth of communciations between the user 
and the environment. 

In analyzing ZOG , one finds that it conforms nicely to 
this paradigm, except it does not have any specific tools to 
support the desired expert system language, 0PS7. In order 
to design these tools a study of the code for both ZOG and 
0PS7 was undertaken. It should be noted that the time to do 
this study took much longer than expected because of the 
size of the two systems and lack of instructional documenta- 
tion of the system cede. The result of this study was the 
design of a reasonable framework for the writing of 0PS7 
programs in ZOG. 

The design of the the subnet framework is the first step 
in the creation of the programming environment. During the 
actual implementation, issues concerning hardware limita- 
tions, the speed with which ZOG can run 0PS7, and the time 
saved by developing CPS7 programs would have to he dealt 
with. These issues have been analyzed and solutions 
suggested. 
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B. EECCMHENDATIONS 



The experience cf working with these two systems will 
undoubtedly pay dividends in the future. The work experi- 
ence gained by studying both ZOG and 0PS7 have instilled in 
the author an appreciation for the effort, both in research 
and manpower, required to design and implement human- 
computer interfaces and new programming languages. Also, 
the author will be leaving Monterey to work with the imple- 
mentation cf these systems onboard USS Carl Vinson. 
Additional formal instruction in these systems will be 
forthcoming, but the time spent on this research has laid an 
important foundation for continued work in this field. 

From this experience, it appears that trying to learn 
about a complex software system in a benign environment is 
difficult, at best. The learning environment must be 
similar to the real world environment, and have support from 
personnel, as well as documentation. Personnel must be able 
to provide to the student the benefits of their experience 
with the system. Further, the available documentation must 
extend beyond system definitions and source code to be of 
any tangible value. 

The time required to understand large, complex software 
systems is difficult to estimate. The size of the system 
will have the greatest impact on the leaning process. The 
next factor is the structure of the software. If the system 
is written in a structured programming language, some struc- 
ture is inherent. Beyond this, the different modules of 
program code must be logically interrelated. Finally, the 
documentation available must extend to instruction on the 
design conventions used and implementations made during 
system development. This kind of documentation will help 
the user understand the overall design approach and prevent 
him from repeating mistakes made earlier in the system 
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development. Oltimately, the system size is the key. It 
may be well documented, have discrete, well defined modules, 
and be supported by many knowledgeable users, but with a 
large system, more time is required to understand enough so 
that the user can comfortably work with the system. 

In future research in the area of interactive environ- 
ments it is strongly recommended that implementation wcrk in 
systems of this scale include experience tour type training 
in the subject system. The time required to bring the 
student up to the level of understanding required to accom- 
plish this kind of work, is otherwise not available. In 
this instance, on-site facilities and technical expertise 
were available, but not to the degree sufficient to support 
further implementation work. 
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APPENDIX A 



FBAMI STROCIDEE SOOBCE CODE 



(GENERAL TYPE DEFINITIONS) 

NOTE: The symbol 3 is used as the pointer label. 



int 




integer; 


Pos Typ 


= 


int; 


stringIS 


= 


string£ 15]; 


zstring 


= 


string [ 255 ]; 


SidTyp 


rr 


stringIS; (Subnet ID) 


FidTyp 


= 


stringIS; (Frame ID) 


UsrIdTyp 


= 


stringIS; (User ID) 



{protection type) 

ProtTyp = int; 

(FRAME STRUCTURES} 

(Short string structures) 



type 



FsISPTyp = 3Fs15typ; (Pointer to frame string 15 } 
FsISTyp = record 

text: stringIS; (a line of text } 

prevstr: FsISPTyp; (Pointer to the previous string } 
nextstr: FsISPTyp; (Pointer to the next string } 
end; (FsISPType record) 



type 

UsrIdPTyp = FsISPTyp; (List of user ID's ) 

(String structure) type 

FsPTyp = SFsTyp; (Pointer to frame string ) 
EsTyp = record 



55 



text: string; £a line of text } 

frevstr; FsPTyp; {Pointer to the previous string } 
nextstr: FsPTyp; {Pointer to the next string } 
end; {FsPType record} 

{Selection structure) 



type 



SelPTyp = aSelTyp; {Pointer to selection) 

SelTyp = record 

k: char; {Selection character) 

nf: FidTyp; {Next frame ID) 

text: FsTyp; {Item of text ) 

row: PosTyp; {Item row position in the frame } 

column: PosTyp; {Item column position) 

10: PosTyp; {Item minimum row position) 

cO: PosTyp; {Item minimum column position) 

11: PosTyp; {Item maximum row position) 

cl: PosTyp; {Item maximum column position) 

action: FsPTyp; {Item action ) 

expand: FsPTyp; {Expansion area ) 

prevsel: SelPTyp; (Previous selection) 

nextsel: SelPTyp; {Next selection } 

end; {SelTyp record) 

{Whole frame structure) 



type 



FPTyp = SFTyp; {Pointer to frame) 

Flyp = record 

nextfr: FPTyp; {Next frame (save list only)} 

frameid: FidTyp; {Frame ID ) 

owners: Usrldlyp; {List fo frame owners) 

crdate: long; {creation date (longer integer) } 

modifier: UsrldTyp; {modifier } 

moddate: long; {modification date ) 

modtime: long; {modification time ) 
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version; 


int; {version number } 


prot; 


ProtTyp 


{frame protection} 


AgCrBit; 


boolean 


{agent created indicator } 


AgModBit: 


boolean 


{agent modified indicator} 


title; 


SelPTyp 


{title info } 


text; 


SelPTyp 


{text info } 


options; 


SelPTyp 


{options lists} 


Ipads; 


SelPT yp 


{local pad list } 


gpads ; 


FidTy p; 


{global pad frame} 


comment; 


FsPTy p; 


{frame comment} 


accessor; 
end; {FTyp 


FsISPTyp; {frame accessor list} 
record} 


me header 


structure} 



type 



FHFTyp = SFHTyp; {Pointer to xrame header} 

FHTyp = record 

nextfr: FHPTyp; {next frame header (save list only) } 

frameid: FidTyp; {Frame ID } 

cwners; Osrldlyp; {List fo frame owners} 

crdate: long; {creation date (longer integer) } 

modifier; UsrIdTyp; {modifier } 

moddate; long; {modification date} 

modtime: long; {modification time} 

version; int; {version number } 

prot: ProtTyp; {frame protection } 

AgCrBit; boolean; {agent created indicator} 

AgMcdBit; boolean; {agent modified indicator} 
end; {FHTyp record} 
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appendix 2 

0PS7 BNF SYNTAX 

This is the BNF syntax for 0PS7. It is included in this 

document for the convenience of the reader. It was 

extracted in total from £Ref. 7]. The symbol is used 

for relation negation. The non-terminal <symbol> stands for 
any name or label. The symbol ... means repeat the 



PRECEEING item any 


number of times. 


<type> 


: := ( type <symbol> <type-field>. . . ) 


<typ6-f ield> 


: := <symbol> = scalar 
: := <symbol> = set : <integer> 

: := <symbol> = vector ; <integer> 


<rule> 


; ;= (p <symbol> <condition>. . . — > 

<action> . . . ) 


<conditicn> 


: := <pattern> 

: ;= -<pattern> 

: := <symbol> <pattern> 


<pa ttern> 


: := ( <symbol> <lhs-term>. . . ) 


<lhs-ter m> 


: ;= <symbol> <relation> <lhs-value> 

; := <symbol> : <integer> <relation> 

<lhs- valu€> 


<lhs-value> 


: := <sc alar-constant> 

: ;= { <scalar-constant>. . . } 

L <scalar-constant>. . . ] 
: ;= <fldval> 


<sc alar-constant> 


: := <symbol> 

: := <integer> 


<f ldval> 


: <symbol> : <symbol> 

: := <symbol> : <symbol> : <integer> 


<relation> 


: := <sc alar-scalar> 
; ;= <sc alar-struct> 
; := <struct-scalar> 
: := <st ruct-struct> 


<scalar-scalar > 


; ;= = 1 1 < j -,< 1 > 1 
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<scalax-struct > 
<str uct-scalar> 
<struct-str uct> 



<action> 



<piD-acticn> 

<wm-action> 



<rhs-term> 

<io-actioB> 

<scalar-value>) 
<scalar- value>) 

<control-action> 



in I -»in 
has I -»has 



in tr 
-•intr 
su b 
-is ub 
su p 
->s up 

<wm-action> 
<pm-action> 
<io-action> 
<variable-act ion> 
<control-acti on> 



:= <rule> 

:= <type> 

:= (make <symbol> <rhs-ter!a>. 
:= (modify <scalar-constant> 

<rhs-term>, 
1= (remove <scalar-constant>. 
:= <reset> 

:= <impiicit-make> 

:= <symbol> = <any-value> 



i 



(write <any-value> ) 

'write <any-value> <vector-value> ) 
write <any-value> <vector-value> 

<scalar-value> ) 
(ifile <scalar-value> 



(ofile 



<scalar-value> 



(close <scalar- value> ) 
(load <scalar-value> ) 



(trace <scalar-value> ) 
’wme <scalar-constant>. 
wm ) 
cs) 
ru n) 

run <scalar-value> ) 
match <scalar-value> ) 



<variabl€-action> : ;= ( let <symbol> = <any-value> ) 



<imp licit- make> 
<any-value> 



:= ( <symbol> <rhs-term>. . . ) 



= [ <scalar-value>. . , 
= ( <scalar-value>. . . 
= <scalar-constant> 
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<rhs-£ield> 
<f a nction> 



<rhs-field> ::= <scalar-constant> : <syiabol> 

: := <sc alar-constant> ; <symbol> 

: <integer> 



<f unction> 



’ <scalar-value> <scalar- valu€> 
- <scalar-value> <scalar-value> 
* <scalar-vaiue> <scaiar-valu€> 
I / <scalar-value> <scalar-value> 
<scalar-value> <scalar-valU6> 
'gensym ) 
genint ) 
accept ) 

accept <scalar- value> ) 
laccept <scalar- value> 

<scalar- vaiue> ) 

(val <symbol> ) 

(append <vector- value> 

<vector- value> ) 

(index <vector- value> 

<scalar- value> ) 

(union <set-value> <set-value> ) 
(in tr <set-value> <set-value> } 
(get <type-name> <scalar-value> 

<scalar-value> ) 



<typ€-name> 



scalar | vector | set 
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